1. Field of the Invention
The present invention relates to computing systems for enterprises and, more specifically, to disaster recovery systems and techniques for reconfigurable, virtualized processing systems.
2. Discussion of Related Art
FIG. 3 depicts a conventional disaster recovery system. Storage facility 302 is located at a first location, and storage facility 304 is located at a second location, typically remote from the first location. Facility 302 may be considered a primary system and facility 304 may be considered as a secondary or fail-over site. Each facility has an identical copy of the data of interest, e.g., on their respective storage. Any desired updates of data at the primary are also sent to the secondary, e.g., via communication path 306. In this fashion, the primary and secondary facilities may maintain identical copies of data.
If a disaster were to happen at the primary site, e.g., a hurricane, computer operations may fail-over to the secondary site. The secondary site has a host computer 308 waiting to handle such failover requests and is pre-configured with the necessary applications (e.g., those that executed on the primary host 310). The secondary site, including its host 308, may then handle the enterprise's computer operations that used to be handled by the primary. When the primary site recovers, the operations may switch back to the primary site if desired.
FIG. 4 depicts an exemplary, multi-tiered application topology. A firewall 402 acts as an interface to the Internet, for example, to receive various requests therefrom. The firewall 402 communicates with a load balancer 404, which attempts to distribute the processing load on the overall system among a multiplicity of processing nodes. For example, the load balancer may distribute requests among a multiplicity of web servers 406a . . . n. Each web server 406, in turn, may perform some analysis of a task it receives and invoke an appropriate application server 408a . . . n. Each application server 408 may in turn interact with database or file server 410a . . . n. Each of the various entities may be executing on its own respective processing or server node.
As suggested by FIG. 4, modem multi-tiered application topologies may become very complicated. Adding to the complication (though not shown in FIG. 4) are the various hubs, switches, cabling, and the like necessary to create the depicted processing network. Moreover, various versions of software may be executing.
To date, a considerable body of expertise has been developed in addressing disaster recovery with specific emphasis on replicating the data. Processor-side issues have not received adequate attention.
To date, processor-side aspects of disaster recovery have largely been handled by requiring processing resources on the secondary site to be identical to those of the first site and to wait in standby mode. This is complicated and costly, as suggested by the complexity of the multi-tiered architecture. Moreover, modem processor networks are often changed for a variety of reasons. If such a network is a primary site network, then the changes also need to be made to the secondary, or else the enterprise risks that its disaster recovery system will not work as expected.
Platforms have been created recently that facilitate the deployment of processor resources. For example, Egenera, Inc. has provided the Egenera Bladefram platform. This platform has an adaptable, internal architecture (more below) so that processing area networks may be rapidly deployed under the control of software configuration commands. An exemplary architecture of such a system is described in U.S. patent application Ser. No. 10/038,354, filed on Jan. 4, 2002, entitled Address Resolution Protocol System and Method in a Virtual Network, and published on Oct. 24, 2002, which is hereby incorporated by reference in its entirety.